This invention pertains to distributed file systems, and more particularly to locating instances of a selected volume over the distributed file system.
In conventional file systems, a client on a workstation can access a specific named volume on a specific named server. As the volume name is human-readable, there could be other volumes in the network with the same name on different servers, but these bear no relation to any other volumes with the same name. Products exist to replicate data between volumes on different servers, but the client is still required to specify which instance of a replicated volume it wants to access.
A Distributed File System (DFS) eliminates the strong tie between a file and the server on which it resides. With DFS, volumes still exist, but they can move between servers or have multiple instances that exist on different servers. The client specifies only the DFS volume name or its Global Unique Identifier (GUID) when accessing files. The advantages of DFS can be generalized to any kind of resource that can be distributed (e.g., printers, scanners, etc.). But without some mechanism to assist the client in finding to which physical server or servers the resource is attached, DFS is of limited value.
There have been several prior attempts to implement distributed file systems. The National Software Works (NSW), implemented by the Advanced Research Projects Agency (ARPA), included a single global volume distributed across multiple physical machines for file storage, a solution that did not scale well. Cronus, a distributed operating system research project undertaken by Bolt Beranek and Newman (BBN) under contract to the Rome Air Development Center (RADC), used a (statistically) unique name for the object as a clue to its location. But if the object was not known by that host (perhaps because it had been moved), the object would have to be located by broadcasting a message on the network. This approach did not scale well, and broadcasting messages can be difficult in any event. The AFS-3 file system by Transarc Corporation included a single back-end database implementation with a well-known name for the volume location servers. This approach is difficult to generalize, and has a single point of failure (the database). Microsoft used reparse points, which contain the full list of hosts where the volume instances can be found. But if a volume moves or a new instance is added, the reparse points must be modified, which is a difficult task.
Accordingly, a need remains for a mechanism that allows a client to locate instances of a resource given the resource""s naming information that is easily scalable, includes redundancies for continued performance, and is easily updated as volumes are added to or removed from the DFS.
To locate an instance of a resource, the management context for the resource name is consulted. The management context identifies a set of location services that can locate instances of the resource. Each location service knows where all resource instances within its management context are located. One of the location services is then queried for the location of resource instances. The location service returns the location of all known instances of any given resource under the location service""s control. One resource instance is selected. The selected resource instance can be contacted and utilized.
If either the location service or the selected resource instance cannot be contacted, alternative location services or resource instances can be used. As each location service knows of all instances of resources in the location service""s scope, and the data and metadata of each resource instance are substitutable for any other resource instance, the techniques for selecting the location service or resource instance from the given sets are not significant.